Team@Work is a system that combines functionality for business planning, work flow definition, business analysis and real-time teamwork task distribution. It allows managers to create sophisticated multi-variant plans, to deploy them fast and efficiently in the whole organization, to supervise every project in real time. Team@Work helps every team member to work synchronized with every other. The system was designed to meet many real life business situations, to handle not only the "happy" scenarios but also exceptions, alternative variants, team members availability etc. Thus Team@Work supports its users in every business situation.
In this section you will learn how Team@Work works. The mechanisms and properties of the system and how they fit to the everyday work will be described. You will understand the real benefits of using Team@Work for all participants of the business work flow: managers, team leaders and team members. You will learn how Team@Work relates to other information systems already used in your organization.
Team@Work is a system equally important for managers who define, supervise and rule the working process and for all team members involved in the processes.
Managers get four major benefits using Team@Work.
the first benefit is the possibilities for sophisticated planning of the business work flow. This includes the unique system for multi-variant planning with alternative scenarios, branches and distributed decision-making mechanisms.
the second benefit is the possibilities for team management, detailed user privileges, granting to team members rights to choose the project development scenarios or even "Go/No go" decisions
the third benefit for managers is the possibility of operative supervision of the workload, status of the running projects and statistics for completed projects. Team@Work supplies enough information to help managers in their permanent efforts to optimise working processes, to solve temporary crises with workload and to watch critical projects.
the fourth benefit is the considerably reduced time between workflow definition and workflow implementation - time between taking decision for workflow changes and the real implementation of these changes in the organization. Teams start working following new workflows immediately after the new workflows are stored in Team@Work system. In most cases people do not need any additional instructions or training.
Team members involved in project execution also have great benefits from Team@Work
on the first place, everybody has actual list of all tasks to be done. This is very important when one person is involved in many similar tasks, belonging to many different running projects. All tasks are collected in a single list, there is no need to seek tasks project after project.
the second benefit is that everybody is guaranteed that all pre-conditions required to start a task are completed before the task occurs in the list. This is particularly useful when a task needs many different activities to be done as pre-conditions. The user is freed from the obligation to check whether everything needed is done before starting the job. The same is true for reporting results of completed tasks: Team@Work is responsible to inform everybody who is waiting for results of the task.
the users are isolated and protected from changes of the workflow, adding new interaction links and removing others. They keep working in the usual manner leaving Team@Work to handle changes.
Team@Work needs very little time. Every user spends only few minutes per day to manage task lists.
Company managers are the first who will start Team@Work usage. They have to define the organization structure of the company and the key persons who will use Team@Work. After that the workflow schemes should be defined, their partition on tasks, the task assignments and time scheduling of each task. The task interactions and dependencies also have to be defined. Different scenarios are described and decision points are fixed. The decision making right are granted as well.
The real Team@Work usage begins after the above information is entered. The server automatically starts to trace each single project based on certain workflow (hundreds and more projects can be defined) by informing its participants for the upcoming tasks. Each participant receives on his display the current list of tasks that should be completed. Only by several mouse clicks he/she informs Team@Work for the job finished and the achievements reached. This is enough for the Team@Work server to analyse the progress and generate the new tasks for the participants.
The whole information concerning the execution progress of every project is saved in the Team@Work server. Information about execution of each task is kept: who exactly has finished it and when. These statistics are very important for the managers who using Team@Work tools can analyse the current company status (current projects, active tasks, task's status, person's charge, etc.) and to help them take operational decisions concerning concrete tasks and projects. Along with this the managers can access the information for the completed projects and the performance of every member in them. This information helps making analysis and allows managers to take strategic decisions concerning improvement of workflow processes, human resource allocation and time scheduling. The analyses usually raise corrections in the workflow schemes. After loading such corrections in Team@Work, the system automatically accepts them and enlists them for execution. So, all users of Team@Work automatically are involved in new working schemes and the whole organization fluently goes into the new working process.
This is the way the Team@Work usage cycle starts from the managers, who define the organization structure, key players and the workflow schemes, moves through every workflow participant providing him the actual information for his tasks and closes the cycle again at managers providing them the needed information for work optimisation.
Now we will describe the basic terms and concepts of Team@Work. At the same time we will describe how the system works.
We will use the common term "organization" to outline that Team@Work can be used in companies as well as in state organizations, consortiums, working groups and all other places, where people team work is needed to be organized. The organization is the place where people work. In the Team@Work system you can define only one organization (nevertheless how distributed it is or how many remote offices or branches it has).
The department is the basic structural unit of the organization. Each department is responsible for separate activity field. Every person in the organization works in a department. One of the workers in every department is appointed as a department leader. As we will see later the department leaders can perform additional activities in Team@Work.
The departments are organized in hierarchical pyramidal structure. Each department structurally belongs to some other. At the top of the pyramid as initial department is the organization itself. We consider it as the "biggest department" and correspondingly we assign to it the organization name. A sample organization is shown in the next figure.
The workers are the end-users of the Team@Work system. They are executors of the specific project tasks. Every worker is counted in the staff of a single department. The main goal of Team@Work is to support the particular worker in the execution and the reporting of his daily job. This support follows three main directions:
to generate and to provide to the user the current tasks lists allocated to him
to collect the preliminary information, needed for each task and to inform everybody who needs task results
to isolate the end-users from the workflow and the organization structural changes.
In other words Team@Work allows everybody to keep doing his job without troubling how it has come to him and where the results go on.
At the same time Team@Work only organizes the interaction among the separate participants into the workflow, but does not do the real work. This is the reason the system is organized in such a way, that the user needs only few minutes per day to work with it.
The business in the organization is usually structured on clear patterns. The common work is divided on separated individual tasks with determined execution time and responsible person. Some of the tasks can be started immediately; others need the results, received at earlier stage. In other words the beginning of some tasks needs other tasks to be completed. The workflow scheme is the structure that holds in itself the dividing of the process into separate tasks and the interactions among them. These schemes are designed by the company managers.
Let look at one simple example of a printing house, offering different printing services. The printing of an advertisement brochure goes roughly through the following stages: define the content; create several variants of graphical design; approve the design; pre-print preparation and finally the print. It can be represented with a linear workflow in which every task depends on the preceding one.
The workflow is the pattern through which the system moves the work. Following the pattern a big count of individual processes that are in different execution stages can be started or executed in one organization at one and the same time. We call these processes "projects". In our example it is possible that the printing house can work out at once ten orders, three of which are in phase graphical design, five are in pre-print preparation and two are in a printing phase. In this case we have ten projects, following one and the same workflow but reaching different execution stages.
On the other hand several workflow schemes can exist in the organization corresponding to different products or services provided by the company. For example: Our printing house can have separate workflows for printing books or magazines.
Workflow parameters. Different projects are recognized by their names. Sometimes however it is not enough. For example, when you print a magazine, it is good to add its name, its number and some other information. The project is the same, but parameters are different. Team@Work allow to attach custom parameters to every workflow. These parameters are recognized by their names. They should be filled with some values when a project is started. There are no limitations about the number of workflow parameters. parameters are recognized by their names. You can learn how to define workflow parameters and how to use them in the Designer documentation.
Project's priority. Different projects, even of the same type, could be of different importance for the organization. This simple fact is concerned in Team@Work by introducing of the concept of "Priority". The priority is an integer number. The bigger is the number the higher is the priority. There is no upper limit for the priority. By default, the "normal" priority is set to 50. When a user starts new project he/she could set its priority to other value. For example, if some project is more important than other, its priority may be set to 200; if it is very important, set the priority to 1000, etc.
As we have already mentioned, the workflow consists of tasks (states) and the links between them. The terms "state" and "task" means one and the same (a piece of work) but seen from different points of view. From the worker's (end-users) point of view it is a task, from the workflow's (managers) point of view it is a state. The task is a separated part of the workflow. Usually it is performed by a single person or at least the responsibility for it is carried out by a single person. For example: in the printing house we mentioned several tasks.
Every task has a clear definition, specified execution term and responsible person. Sometimes, when the project is started, it is very difficult to point the exact executor of a task, but it is ever known that this task is an obligation of a certain department. In such cases the task can be defined as a common department task. The department staff decides itself who will be the concrete executor. In Team@Work the common tasks are treated in a special way.
Task's priority. By default when a project starts every task receives its priority value. Sometimes however, there are special tasks in the workflow which need more attention. You can mark these tasks by rising their priority in the workflow definition. Every task has its own priority modifier, which is also an integer number. This priority modifier is added to the project's priority. In other words, to calculate the task priority add its priority with the priority of the project. The modifier is set to zero by default which means the task has the same priority as the whole project. Positive priority modifier means the task is more important.
There is an important difference between project's priority and task's priority modifier. The project's priority is defined by the user who starts the project. This is a tactical decision based on the concrete business situation. The task's priority modifier is defined by the manager who creates the workflow scheme. It is a strategic decision to rise the priority of certain task in the workflow.
So, up to now we have learned:
Several diferent workflows can exist in the organization. They are the patterns that move the work through. The workflows are split into separated tasks and the links between the tasks show the dependencies of some tasks from the results of the others.
A great number of projects following different workflows and being at different execution stages can be run at one and the same time in the organization.
One and the same person can be involved in the execution of different tasks from different projects following different workflows.
The links between the different states show how the project moves from the beginning to its end. We can represent the links by arrows indicating the transition from one task to another. When two tasks are connected with a link, this means that the second task should be started after the first one. Thus the workflow order is set up.
Here are the terms and explanations related to the state links:
Each link binds two states - "starting" state and "ending" state. For the starting state the concrete link is "output" and for the ending state it is "input". Each state can have several input and several output links. The states that do not have input links are called "initial states". The workflow starts from such initial states. States that do not have output links are ends for the process.
We can think that the links are used to transmit "signals" between connected tasks. The signal always goes from the starting to the ending state and always is only one. When a signal has been set to a link we say that a "transition" has been done and the link has been "activated".
You can define different features and dependencies of the links at one state. This is one of the most powerful features of Team@Work that vastly distinguishes this system from all other workflow management systems. Thus the project participants are given the chance to manage its progress and to make important decisions depending on the concrete circumstances.
The input links are two types: notification and activation ones.
An input link is an activation link when the transition through it leads obligatory to the starting of the corresponding receiver state, i.e. the task that has received the signal is activated immediately.
The transition through notification link does not necessarily lead to starting the receiver state - actually if all input links are of notification type, they all should be activated in order to activate the state.
In other words, to start a task we need one of the following:
either an activation link has been activated,
or all input links have been activated.
Let us show this with an example: A certain state has three input notification links (i.e. it has three transition states connecting our state via links)
At 10 o'clock "Task 1" is completed and "Link 1" is activated. "Task 4" remains passive because all notification links should be activated for its awaking.
At 11 o'clock the same happens with "Task 2". "Task 4" is still passive.
At 12 o'clock "Task 3" is completed. "Link 3" is the last necessary signal and then "Task 4" becomes active.
Let now suppose that "Link 2" is not a notification but an activation link. In this case "Task 4" will be started at 11 o'clock - immediately after the transition through the activation link without waiting the execution of the remaining notification transitions.
This is the difference between the notification and the activation links. Normally (by default) the input links are notification ones. This guarantees that the task will be started after all its preconditions are fulfilled.
The output links can participate in much more complex interactions than the input ones. This complexity corresponds to the concrete different situations the workflow has to reflect. We will point out again that the complexity is limited only on the phase of workflow definition. The concrete users are isolated from these details. They have simple and clear interface to manipulate links and can concentrate on doing the job and making the specified decisions.
The simplest situation is when the user marks off "I have completed this task" and all output links are activated. Such links are called "automatic". The typical workflow management systems are limited up to such automatic links. In the real life however different situations may occur. Not always the direction in which the project should continue can be pre-defined. Sometimes variants are possible. The owner of the task can decide the exact way of the project execution depending on the concrete circumstances.
EXAMPLE: A small home repairing company have several offices (East, West, South and North office) that cover different parts of the town. The company receives orders by phone. Receiving a call the telephone operator decides which office to involve. Obviously, if the address is in the Eastern part, he/she will not give it to the office servicing Western regions. The workflow can have the following form:
The telephone operator can complete his/her job by choosing one of the links to the offices and the process goes on only through this link.
Choose where to send the order .
Send it to the North department
Send it to the East department
Send it to the South department
Send it to the West department
Only the chosen department will receive the task. Other links will never be activated hence other departments will not have any work on this concrete project.
As we have seen in this example you can define a group of output links only one of which have to be activated. Such a group is called "selector". One and only one link from a selector group must be activated.
Let have another case when several inks or no one from a given group can be activated. Such a group is called "options". An example for such a group: After the service is completed, the client can pay in cash or not, the job may need some materials from the warehouse or not. If the client has paid in cash the pay-desk should be informed, that the money have to come in their box. If some materials were used, a notice should be placed. Here is a workflow fragment:
The two output links connect our tasks with the tasks "Paid in cash" and "Materials used". They both depend on the concrete situation that cannot be foreseen. That is why we put them in an "options" group and the person who executes the task marks them depending on the case.
Options .
Paid in cash
Materials used
"Timer" links. Sometimes it is important to start a task after a fixed time period. Team@Work supports a special link type named "timer" links. They have a time parameter which defines the time after which the link is activated regardless of the user's actions. Time count starts with the start of the task which owns the output timer link. For example, if a task has a timer link set to four days, this link will be activated exactly after four days counted from the start of the task regardless of the user's actions. Timer links are not visible for the user and he can not influence to them. If the user completes the task before the time it will disappear from his task list, but the timer link will be activated on the exact moment.
Timer links are useful in workflows (and projects) that are based on a strict time schedule and the mutual dependences of the tasks are not so important. Another useful case is "synchronization on start": if you want to start a task immediatemmy when another task has been started, create a timer link between them and set the time parameter to zero.
Time parameter of non-timer links: automatic link activation. All non-timer links (automatic, options and selectors) also have a time parameter. This parameter however plays a different role - a role of time guard. If the link has not been activated until the defined time period, it is activated automatically. Thus the defined time is the latest time when the link must be activated. If a task has been completed normally, all time activation rules are canceled for it - no time activations left after the normal completion of a task. (for example, this means that if an optional link has a time defined, but it has not been selected and the task has been completed in time, this link will not be activated). The time parameter is optional: if you do not define its value, then the link will not receive this functionality.
To summarize:
The output links can be grouped in four kinds of groups:
Automatic - all such links are activated by the task finish. No user action is needed in this case.
Selector - only one link from this group will be obligatory activated. The user is obliged to chose the link that should be activated.
Options - from this group an arbitrary number of links can be activated - from no one to all. The user chooses which links to activate. If he doesn't do anything, no link is activated.
Timer - links, that are activated at a fixed moment after the task starts.
For each task you can define as many different groups as you need
You can define optional time guard for each link which will activate the link automatically if the task has not been completed in time.
Here are some guidelines for usage of different types of links.
Automatic links are used in cases when the new task strictly needs some previous tasks to be entirely completed.
Selectors are used when the workflow has several different paths to be continued and the decision which way to go depends on the task owner.
Options are used to mark possible results of a task, which require some further actions, but are not necessarily required for project's progress.
Timer links are used in cases where a strict time schedule must be followed.
Another unique Team@Work feature is the possibility to plug in external partners in the workflow schemes as task receivers and task executors. In fact there is no difference concerning the workflow performance between the organization internal users and the external ones. The external partner simply has to be defined, to give him/her user name and password and he/she immediately can join the workflow scheme. The Team@Work server interprets him as usual user but only with basic rights to manipulate tasks. The external user handles the Team@Work client part in the same way as the organization members. He/she can use web client immediately without any installation efforts, or can install Team@Work client.
There exists an interesting opportunity to define links among external partners. For example, if the work of an external partner affects the tasks of another external partner nothing can stop us to define links among their tasks. In such a way we can transfer parts of the workflow process entirely outside our organization.
Team@Work is extremely tolerant towards changes into organization structure and workflow schemes. The main principle in handling changes is minimum affection to end users. Managers do the changes. They can change the organization structure, replace, add and delete departments, staff and external partners, change the structure of the workflow processes and the different workflow schemes. The moment changes are entered into Team@Work they are accepted; the system automatically adjusts itself to them and starts working with the new structures. All this happens in a real time without stopping, adapting or reinstalling any part of the system. Practically many of the changes do not influence the work process participants at all.
We will illustrate this with some expansions of the workflow scheme from the example. Let see the following situation: the telephone operator who receives orders for repairing have to inform special Control department for orders registration. After the job is completed each ("North", "South", "West" or "East") department should send information notice to this control department. With these extensions the workflow changes in the following way:
Both new tasks "Register order" and "Order completed" are assigned to the new Control department.
Company managers design these changes. The two new tasks are assigned to the Control department. All new links are automatic and informational. The new department starts receiving tasks. What is changed in former participants workflow? Nothing! They continue to operate in absolutely the same way. They even will not notice any change in their interface. Team@Work takes charge of the new tasks and links.
Let us now view another example: The company expands its activity (maybe because it uses Team@Work!) Bigger stream of orders enforces managers to set up new unit - "Central department". It works in the same way as the other four. The manager adds the corresponding states and links in the workflow. This results in a new branch containing new task ""Central" and links from "Order" to "Central" and from "Central" to "Order completed": just like "North", "East" etc. What does this change into the rest staff performance? Almost nothing! Only the telephone operator will have one option more in his/her menu.
Choose where to send the order .
Send to the North department
Send to the East department
Send to the South department
Send to the West department
Send to the Central department
That is it! During all these changes Team@Work automatically generates the new user interface. No other changes have to be made.
Team@Work supports some of most popular techniques for work flow analysis such as Gantt charting and Critical path analysis. They are well known and widely used. The new elements introduced in Team@Work are again multi-variant schemas and real-time tracking.
If a project consists of a single execution path its Gantt chart is easy to draw and easy to understand. Things become much more complex when we deal with multi-variant work flow where some scenarios may happen and other may be cut. Team@Work handles correctly all the cases and generates the actual and most informative Gantt charts for each running project. Also the information for already completed tasks is automatically included in the Gantt chart with actual time used for every finished task. Thus the manager has real-time comparison between project plan and project progress - a very useful project health monitor.
The critical path of a work flow is a path containing tasks which must not be delayed. If a task laying on the critical path is not completed in time the whole project will be delayed. This is by definition. Things are simple and clear in theory. In practice however the critical path may vary if some of tasks running in parallel have been delayed for long enough time. In some cases the critical path may change considerably and more than once. This dynamics is calculated automatically by Team@Work server and managers have the actual status of the critical path during the whole project execution time. Moreover, every team member receives a "CP" mark on tasks in his list for every task that (currently) is on the critical path. This informs him about the importance of the task. In such a way all Team@Work users are kept informed and involved in project completion in time.
Team@Work does not aim the replacement of other information systems used in your organization. Team@Work is only a single efficient and dynamic notification system that informs (reminds) for the upcoming tasks. Your basic job is done as before Team@Work is used. In this aspect Team@Work is an extension of your already existing information structure. Therefore our aim was to facilitate the Team@Work usage to such an extent that it should not take more than few minutes per day. Keep working as usual and let Team@Work to carry out the interactions among your team.
Team@Work supports many of the most popular world languages. During the installation phase you chose among several languages. Our team works constantly on creation of new language packages that can be changed on the fly.
Herein we will describe the typical sequence of activities starting from Team@Work download to its full business usage in your organization. In the proposed scenario we presume the following:
the Team@Work server runs on a separate computer
the organization has a determined person in charge with the definition of workflow process and organizational structure. This person we be called "Organization manager" or simply "Manager"
another person is occupied with the definition of with the users rights as well as their authentification data (user name and password). This person will be called "Administrator"
Neither of the above is absolutely required: Team@Work server may be run on a computer used for other activities (that is often true), the Manager can be an administrator too (although less probable).
As you can read in the "Installation guide" Team@Work consists of two installation packages: "Server" and "Applications".
This is the actions sequence that puts in operation Team@Work:
|
|
Action |
Carried by |
Described in |
|
1 |
Install the server. If want to run it in Internet install the Web server and install in it the Team@Work web application |
Administrator |
Server Installation guide |
|
2 |
Start the server |
Administrator |
Team@Work Server's help |
|
3 |
Install the client package on the personal computers of the manager and administrator |
Administrator |
Client Applications Installation guide |
|
4 |
Insert the organization structure |
Manager
|
Team@Work Designer help |
|
5 |
Insert the key persons and their roles |
Manager |
Team@Work Designer help |
|
6 |
Insert one or several workflow schemes. Do not forget to assign each task to a department or concrete person |
Manager |
Team@Work Designer help |
|
7 |
Define users' data: names, passwords |
Administrator |
Team@Work Control Center help |
|
8 |
Install the client application at the users' computers (skip this step if everyone works only in the Internet) |
Administrator |
Installation guide |